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ABSTRACT 


Two  examples  are  used  to  show  how  the  SIMULA  restriction 
on  the  use  of  dot  notation  to  reference  attributes  of  classes 
limits  the  abstraction  mechanism  provided  by  classes. 
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CONCERNING  CLASSES  WITHIN  CLASSES 


The  SIMULA  Common  Base  Definition  [1],  Section  7.1.2,  restricts  the 
use  of  dot  notation  to  refer  to  attributes  of  classes  as  follows: 

The  remote  identifier  X.A  ia  valid  if  the  following  conditions  are 

8atiafied: 

1)  The  value  X  ia  different  from  none. 

2)  The  object  referenced  by  X  has  no  class  attribute  declared  at 
any  prefix  level  equal  or  outer  to  that  of  C. 

While  the  restriction  (2)  makes  it  a  great  deal  easier  to  implement 
SIMULA,  it  also  serves  to  make  it  much  more  difficult  to  use  classes  as 
an  abstraction  mechanism  and  to  share  concepts  Implemented  as  classes. 

I'd  like  to  illustrate  the  difficulty  with  two  examples.  The  first 
is  from  a  program  that  I  have  been  working  with  for  some  time.  In  this 
program,  there  is  a  need  for  linear  lists  of  unknown  length.  Different 
lists  have  different  kinds  of  nodes  and  different  attributes  are  of  in¬ 
terest.  All  of  these  lists  share  some  attributes  which  are  not  acces¬ 
sible  outside  the  structures.  Thus,  it  is  reasonable  to  declare: 


class  linked_list; 

protected  l_l_node, 
insert , 
head; 
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class  l_l_node ; 
begin 

ref(l  1  node)  link 
end  of  l_l_node; 


procedure  Insert  (element) ;  ref(l  1  node)  element; 
begin 

element. link  :-  head; 
head  :-  element 
end  of  insert;  1 


ref (1  1  node)  head; 
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end  of  linked  list; 


2. 
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This  class  declaration  Is  used  for  many  structures  which  Include 
stacks  of  tokens  and  stacks  of  reals.  The  class  token_stack  might  be 
declared  as  follows: 

llnked_llst  class  token_stack; 

not  protected  push, 
pop; 


begin 

l_l_node  class  exp_node(v);  ref (token)  v; 
begin  end; 

procedure  push(ld);  ref (token)  id; 
insert  (new  exp  node (id)); 

ref (token)  procedure  pop; 
if  head  ■/■  none 
then  begin 

pop  head  qua  exp_node.v; 
head  head. link 

end 

else  pop  none; 
end  of  token_stack; 


This  declaration  provides  stacks  of  tokens  and  a  pop  executed  on  an  empty 
stack  returns  the  object  none.  This  return  value  is  tested  by  the  pro¬ 
gram  that  uses  the  stack. 


3. 


A  similar  declaration  of  class  real__stack  Is: 

linked_llst  class  realjstack; 

not  protected  push, 
pop; 


begin 

l_l__node  class  real_node(v) ;  real  v; 
begin  end; 

procedure  push(val) ;  real  val; 

Insert (new  realjaode(val)) : 

real  procedure  pop ; 
if  head  ■/•  none 
then  begin 

pop  :■  head  qua  realjnode. v; 
head  head. link 
end 

else  ("popping  empty  real  stack."); 
end  of  real  stack; 


The  nodes  placed  on  this  stack  differ  from  the  nodes  on  the  token  stacks. 
In  addition,  popping  an  empty  stack  of  reals  is  a  fatal  run  time  error 
and  execution  is  terminated  in  this  case. 

These  declarations  make  it  possible  to  state  the  difficulty  clearly. 
It  is  possible  to  use  the  push  and  pop  attributes  of  either  a  token_stack 
or  a  real  stack  as  follows: 


Inspect  new  token_stack  do 
begin  . . .  end ; 


or 


inspect  new  realjstack  do 


4. 
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However ,  it  is  not  possible  to  use  both  stacks  simultaneously  because 
the  following  la  illegal  by  restriction  (2) . 


ref (token)  y; 
real  z; 

ref (token  stack)  t_s; 
ref (real  stack)  r_s; 


if  r_s.pop  <  0 

then  t_s.push(y) 
else  r_s.push(z); 


There  are  many  obvious  technical  devices  for  avoiding  this  diffi¬ 
culty  but  they  all  make  it  difficult  to  define  objects  in  terms  of  other 
objects.  For  example,  one  could  rearrange  the  declarations  and  duplicate 
code  or  replace 

t_s.push(y) 


with 


inspect  t_s  do  push(y) 

Both  of  these  solutions  as  well  as  others  make  it  difficult  to  use  class¬ 
es  as  an  abstraction  mechanism  and  they  are  forced  by  restriction  (2) . 

As  a  second  example,  which  is  typical  of  data  structure  definitions, 
arises  as  follows.  Suppose  a  stack  of  Integers  is  to  be  implemented  with 
four  procedure  attributes  push,  pop,  full  and  empty.  The  class  declara¬ 
tion,  as  it  concerns  the  user  of  these  stacks  is: 


5. 


class  stack(n) ;  value  a;  Integer  a 
not  protected  push. 

Pop, 

full, 

empty; 


procedure  push(x);  value  x;  Integer  x; 


Integer  procedure  pop ; 


boolean  procedure  full; 


boolean  procedure  empty; 


end  of  stack; 

In  some  cases.  It  may  be  desirable  to  Implement  this  kind  of  stack  with 
an  array  and  In  other  cases  It  may  be  desirable  to  Implement  this  kind 
of  stack  using  linked  lists. 

If  the  stacks  are  implemented  as  arrays,  the  procedure  declarations 
would  be  followed  by: 

Integer  stackjpointer; 
integer  array  stack_store[i:n] ; 
stack_pointer  :■  1 

and  the  procedure  bodies  would  be  filled  In  In  the  obvious  way. 

On  the  other  hand,  if  the  stacks  are  implemented  as  linear  lists 
the  parameter  n  would  be  ignored  and  the  procedure  declarations  would 
be  followed  by: 


6. 


class  stack_node(element) ;  value  element;  Integer  element; 
begin 

ref (stack  node)  link 

end; 

ref(atack  node)  head 

and  the  procedure  bodies  are  filled  in  In  the  appropriate  way.  Here  Is 
an  example  of  the  declaration  of  push: 


procedure  push(x) ;  value  x;  integer  x; 
begin 

ref (stack  node)  temp ; 
temp  new  stack  node(x); 
temp. link  :-  head; 
head  link 
end  of  push; 

This  second  declaration  of  stack  violates  restriction  (2)  (as  en¬ 
forced  by  the  DEC- 10  implementation) .  In  spite  of  the  fact  that  the 
accessible  attributes  of  these  two  classes  are  the  same  (except,  of 
course,  in  the  second  version  the  procedure  full  always  returns  true) 
the  two  class  declarations  are  not  lnterchangable! 

The  array  implementation  permits  the  use  of  dot  notation  to  refer 
to  the  four  accessible  attributes  and  the  second  prohibits  the  use  of 
dot  notation.  This  means  that  the  two  implementations  are  not  inter- 
changable  inspite  of  the  fact  that  they  are  functionally  equivalent. 
This  is  a  consequence  of  restriction  (2) . 

These  examples  illustrate  my  claim  that  restriction  (2)  limits  the 
use  of  classes  for  program  abstraction.  In  my  opinion,  this  evidence 
supports  the  removal  of  restriction  (2) . 
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